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Abstract 


The 3rd-Generation Partnership Project (3GPP) has selected Session 
Initiation Protocol (SIP) as the session establishment protocol for 
the 3GPP IP Multimedia Core Network Subsystem (IMS). IMS is part of 
Release 5 of the 3GPP specifications. Although SIP is a protocol 
that fulfills most of the requirements for establishing a session in 
an IP network, SIP has never been evaluated against the specific 3GPP 
requirements for operation in a cellular network. In this document, 
we express the requirements identified by 3GPP to support SIP for 
Release 5 of the 3GPP IMS in cellular networks. 
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Les 


Introduction 


3GPP has selected SIP [2] as the protocol to establish and tear down 
multimedia sessions in the IP Multimedia Subsystem (IMS). 3GPP 
Technical Specification 23.228 [28] describes the IMS. 3GPP 
Technical Specification 24.228 [29] contains a comprehensive set of 
session flows. 3GPP Technical Specification 24.229 [30] describes 
the usage of SIP by the various IMS nodes. 


This document is an effort to define the requirements applicable to 
the usage of the SIP protocol suite in cellular networks, 
particularly in the 3GPP IMS for Release 5 of the 3GPP 
specifications. Further releases of the 3GPP specifications may 
contain additional SIP requirements. This document focuses on the 
requirements identified for the 3GPP Release 5 IMS. 


The rest of this document is structured as follows: 


o Section 3 offers an overview of the 3GPP IMS. Readers who are not 
familiar with it should carefully read this section. 


o Section 4 contains the 3GPP requirements to SIP. Requirements are 
grouped by category. Some requirements include statements on 
possible solutions that would be able to fulfill them. Note that, 
as a particular requirement might be fulfilled by different 
solutions, not all the solutions might have an impact on SIP. 


This document is advisory in nature. Its primary purpose is to help 
the IETF understand the IMS environment. Given this better 
understanding, we expect that the IETF can more effectively evolve 
the SIP protocol. The IETF will not respond to the requirements 
given in this document on a point-for-point basis. Some requirements 
have been and/or will be met by extensions to the SIP protocol. 
Others may be addressed by effectively using existing capabilities in 
SIP or other protocols, and we expect that individual members of the 
SIP community will work with 3GPP to achieve a better understanding 
of these mechanisms. Some of the requirements in this document may 
not be addressed at all by the IETF, although we believe that the act 
of documenting and discussing them is in itself helpful in achieving 
a better all-around understanding of the task at hand. 


Conventions 


This document does not specify any protocol of any kind. Therefore, 
the usage of the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 

"OPTIONAL" in this document, as described in RFC 2119 [1], does not 


apply. 
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32 


Overview of the 3GPP IMS 


This section gives the reader an overview of the 3GPP IM CN Subsystem 
(IMS). It is not intended to be comprehensive, but it provides 
enough information to understand the basis of the 3GPP IMS. Readers 
are encouraged to find a more detailed description in the 3GPP 
Technical Specifications 23.060 [27], 23.228 [28], and 24.228 [29]. 


For a particular cellular device, the 3GPP IMS network is further 
decomposed in a home network and a visited network. 


An IMS subscriber belongs to his or her home network. Services are 
triggered and may be executed in the home network. One or more SIP 
servers are deployed in the SIP home network to support the IP 
Multimedia Subsystem. Among those SIP servers, there is a SIP 
serving proxy, which is also acting as a SIP registrar. 
Authentication/Authorization servers may be part of the home network 
as well. Users are authenticated in the home network. 


A SIP outbound proxy is provided to support the User Agent (UA). The 
SIP outbound proxy is typically located in the visited network, 
although it may be located in the home network as well. The SIP 
outbound proxy maintains security associations between itself and the 
terminals, and interworks with the resource management in the packet 
network. 


The SIP outbound proxy is assigned after the mobile device has 
connected to the access network. Once this proxy is assigned, it 
does not change while the mobile remains connected to the access 
network. Thus the mobile can move freely within the access network 
without SIP outbound proxy reassignment. 


The home network may also support one or more SIP edge proxies. 
These nodes may act as the first entry points for SIP signaling to 
the home network and may determine (with the help of location 
servers) which SIP registrar server to assign to a particular user. 
Typically the address of the home network SIP edge proxy is 
configured in DNS in the form of a DNS Naming Authority Pointer 
(NAPTR) and Service (SRV) records for SIP. 


Additionally, home and visited networks may deploy, if required, a 
SIP-hiding proxy. The main purpose of the SIP-hiding proxy is to 
hide the network configuration. 


The 3GPP IM CN Subsystem is designed to be access independent. 
Access is granted from 3GPP cellular terminals or from other 
terminals that use other accesses out of the scope of 3GPP. 
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3GPP cellular IP Multimedia terminals use the existing General Packet 


Radio Service (GPRS) [27] as a transport network for IP datagrams. 
The terminals first connect to the GPRS network to get an IPv6 
prefix. In order to do this, the terminals must perform a GPRS 


Attach procedure followed by a GPRS PDP Context Activation procedure. 
These GPRS procedures are required to be completed before any IP 
Multimedia session can be established. 


As a result of the above-mentioned GPRS procedures, the terminal has 
built an IPv6 address. The IPv6 address belongs to the same network 
address space as does the SIP outbound proxy. The address does not 
change, as the mobile terminal moves while still attached to the same 
network address space. 


If the terminal moves from a GPRS access to another GPRS access, the 
above-mentioned GPRS procedures needs to start from the beginning to 


allocate an IPv6 address to the terminal. 


Figure 1 shows an overview of the 3GPP architecture for IM CN 


Subsystem. 
4------------- + 4---------------- t 4---------------- t 
| ly J | | decem s di 
| | | | | | sip | | 
| | | | | |server| | 
| | a MEME 
ee | E | | / | 
4------ t 4------ t 
| || fee] | | jee 
| | ---| tg iy pier |--|----|server|----|---|-|server| 
+--+ | NES 4------ + | | +------ + | 
| | | | | | 
SIP | GPRS access | | Visited Network | | Home Network | 
dev fossa ea dus peces + 4---------------- + 
Figure 1: Overview of the 3GPP IMS architecture 
Another possible future configuration is depicted in Figure 2. In 
that case, a general-purpose computer (e.g., a laptop computer) is 
connected to a GPRS terminal. The computer hosts the Multimedia 
application (comprising SIP, SDP, RTP, etc.). The GPRS terminal 


handles the radio access and the GPRS connectivity. Note that, for 
the sake of clarity, in this example the home network has not been 
depicted in the figure. 
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4------------- + +---------------- + 
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Figure 2: A computer connected to a GPRS terminal 


Services are typically executed in an application server. The 
interface between the SIP server and the application server is based 
on SIP. However, certain operators may want to reuse the existing 
technology, and therefore, they may need to interoperate SIP with 
protocols such as CAMEL/Intelligent-Network or Open Services 
Architecture (OSA). 


4. 3GPP Requirements on SIP 

4.1. General Requirements 
This section does not specify any particular requirement for SIP. 
However, it includes a list of general requirements that must be 
considered when developing solutions to particular requirements. 

4.1.1. Efficient Use of the Radio Interface 
The radio interface is a scarce resource. As such, the exchange of 
signaling messages between the mobile terminal and the network should 
be minimized. All the mechanisms developed should make an efficient 
use of the radio interface. 
See also the related requirements in Section 4.4. 

4.1.2. Minimum Session Setup Time 
All the procedures and mechanisms should have a minimum impact on the 
session setup time as perceived by the user. When there is a choice 
between performing tasks at session establishment and prior to 
session establishment, then tasks should be performed prior to 


session establishment. 


See also the related requirements in Section 4.4. 
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4.1.3. Minimum Support Required in the Terminal 


As terminals could be rather small devices, memory requirements, 
power consumption, processing power, etc., should be kept to a 
minimum.  Mandating support for additional protocols in the terminal 
must meet this requirement. 


4.1.4. Roaming and Non-roaming 
All the requirements must be met for both roaming and non-roaming 


Scenarios. There should not be a significant change in the signaling 
procedures between roaming and non-roaming scenarios. 


4.1.5. Terminal Mobility Management 


As terminal mobility is managed by the access network, there is no 
need to support terminal mobility management in SIP. 


4.1.6. IP Version 6 


3GPP IMS is solely designed to use IP version 6. As a consequence, 
all protocols must support IPv6 addresses. 


4.2. SIP Outbound Proxy 

4.2.1. SIP Outbound Proxy 
A SIP outbound proxy is provided to support both roaming and 
non-roaming scenarios. The SIP outbound proxy may be located either 
in the home network or in the visited network. 


4.2.2. Discovery of the SIP Outbound Proxy 


There must be a general mechanism whereby the mobile device (UA) 
learns the SIP outbound proxy address. 


The DHCPv6 option for SIP servers in RFC 3319 [19] seems to fulfill 
the requirement. 


In addition to the above-expressed requirement, the 3GPP access 
network may provide the SIP outbound proxy address during access 
network bearer establishment. This is considered a less general 
mechanism, though. 
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4.3. Registration 


The home network must maintain one or more SIP registrars. The SIP 
registrar authenticates the user and registers the IP address where 
the user can be located. 


Once the terminal is switched on, the mobile device UA reads its 
configuration data. This data may be stored in a SIM card or in any 
other memory device. The configuration data contains an 
identification of the home network. The device finds the SIP 
registrar address from the home network domain name. The terminal 
sends the registration through the SIP outbound proxy. 


In order to support the search of the registrar, the home network 
contains one or more SIP servers that may be configured in DNS with 
the NAPTR/SRV record of SIP. These are the home network edge 
proxies. Their mission is to serve as the first points of contact in 
the home network, and to decide (with the help of location servers) 
which SIP registrar server to assign to a particular user. 


The procedures specified in RFC 3263 [10] applied to a REGISTER 
message seem to be sufficient to meet this requirement. 


4.3.1. Registration Required 


A user must register to the IMS before he/she can receive any 
invitation to any sessions. In addition, it is desirable for the 
user to register before initiating any sessions. The following 
factors contribute to the rationale behind this: 


1. The SIP serving proxy in the home network needs to know when and 
from which terminal the user is available, in order to route 
received SIP requests for sessions and services. 


2. The user can be pre-authenticated early so that authentication 
does not contribute to post-dial delay. The procedure should not 
have a penalty on the session setup time (see also the 
requirement stated in Section 4.1.2). 


3. The user is assigned a particular serving proxy. The serving 
proxy downloads the service profile for that user to trigger 
services. 


Therefore, 3GPP has mandated the mobile device UA to register before 
the mobile device UA initiates any session. 
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4.3.2. Efficient Registration 


Due to the scarce radio interface resource, a single registration 
must be sufficient to ensure that the mobile UA is reachable from 
both the home and the visited networks. 


A single REGISTER message, addressed to the registrar, may traverse 
the SIP outbound proxy. This can install, if needed, soft 
registration states in the SIP outbound proxy. 


4.3.3. Registration for Roaming and Non-roaming Cases 


Independent of whether the UA is roaming, it is desirable for the 
registration procedure to be the same. 


4.3.4. Visited Domain Name 


The home network must be able to validate the existence of a roaming 
agreement between the home and the visited network. The home network 
needs to validate that the user is allowed to roam to such a visited 
network. Therefore, there must be a mechanism whereby the visited 
network identity is known at registration time at the home network. 


It is acceptable to represent the visited network identity either as 
a visited network domain name or as a string. 


4.3.5. De-registration 
4.3.5.1. De-registration of Users 


There must be a procedure for a user to de-register from the network. 
This procedure may be used, for example, when the user deactivates 
the terminal. 


We believe that a REGISTER with an expiration timer of 0 will meet 
the requirement. 


4.3.5.2.  Network-initiated De-registration or Re-registration 
In a number of situations a network needs to de-register or trigger a 
re-registration of a previously registered UA. Examples of usage are 
described in sections 4.3.6.3, 4.3.6.4, and 4.3.6.5. 
This implies a need for a notification mechanism whereby the UA can 


be notified of the de-registration, or of a request for 
re-registration. 
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We believe that this requirement is met by the SIP-specific event 
notification [12] and a registration event package [14]. 


4.3.5.3. Network-initiated De-registration, Network Maintenance 


There might be cases in which the SIP serving proxy has to shutdown; 
e.g., due to maintenance operation. Although this situation is not 
likely to happen in everyday situations, it is desirable to have a 
mechanism to inform the UA that his current registration is being 
cancelled. The UA may initiate another registration process that 
will lead to the selection of a new SIP serving proxy. 


4.3.5.4. Network-initiated De-registration, Network/Traffic Determined 


The system must support a mechanism to avoid inconsistent information 
Storage and to remove any redundant registration information. This 
case will occur when a subscriber roams to a different network 
without a prior de-registration. This case occurs in normal mobility 
procedures when the user roams from one access network to another, or 
when new service conditions are imposed on roamers. 


4.3.5.5. Network-initiated De-registration, Administrative 


For different reasons (e.g., subscription termination, stolen 
terminal, etc.) a home network administrative function may determine 
a need to clear a user's SIP registration. It is desirable to have a 
mechanism whereby the SIP serving proxy can inform the UA that its 
registration is being cancelled. 


There must be a procedure for the SIP serving proxy to de-register 
users. The de-registration information must be available at all the 
proxies that keep registration state and the UA. 


We believe that a procedure based on SIP-specific event notification 
[12] and a registration event package [14] will meet this 
requirement. 


4.4. SIP Compression 


The radio interface is a scarce resource, and typically the available 
bandwidth over the radio interface is limited. These two factors 
seem to limit the transport of possibly large SIP messages over the 
air interface. Particularly, the session setup time might be 
extended due to the time needed to transport SIP messages over a 
limited bandwidth channel. 
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On the other hand, the number and size of certain SIP header values, 
such as Via or Record-Route, seems not to be limited. A mobile 
device UA may present limitations in the available memory to store 
this kind of information. 


Therefore, there must be a mechanism to efficiently transport SIP 
signaling packets over the radio interface, by compressing the SIP 
messages between the mobile device UA and the SIP outbound proxy, and 
between the SIP outbound proxy and the mobile device UA. Note that 
compression of IP and transport layer protocol headers that carry 
these SIP messages is also a requirement, although we believe that 
this does not have an impact on SIP. 


4.4.1. Compression Algorithm Independence 


The chosen solution(s) must be able to allow the operation under 
several different compression algorithms. 


4.4.2.  Extensibility of the SIP Compression 
The chosen solution(s) must be extensible to facilitate the 
incorporation of new and improved compression algorithms in a 
backward-compatible way, as they become available. 

4.4.3. Minimal Impact of SIP Compression on the Network 
Application-specific compression must minimize impacts on existing 
3GPP access networks (such as base stations transceivers). On the 
other hand, the compression mechanism should be independent of the 
access; e.g., the compression must be defined between the mobile 
device UA and the outbound SIP proxy. 

4.4.4. Optionality of SIP Compression 


It must be possible to leave the usage of compression for SIP 


signaling optional. To facilitate mobile terminal roaming between 
networks that are using compression, the mobile terminal should 
always support SIP signaling compression. If compression is not 


supported, communication may continue without compression, depending 
on the local policy of the visited network. 


4.4.4.1. Compression Reliability 


The compression mechanism should be reliable and able to recover 
automatically from errors generated during the decompression. 


Garcia-Martin Informational [Page 12] 


RFC 4083 3GPP R5 Requirements on SIP May 2005 


4.5. QoS Requirements Related to SIP 


4.5.1. Independence between QoS Signaling and SIP 


The selection of QoS signaling and resource allocation schemes must 
be independent of the selected session control protocols. This 
allows for independent evolution of QoS control and SIP. 


4.5.2. Coordination between SIP and QoS/Resource Allocation 
4.5.2.1. Allocation before Alerting 


In establishing a SIP session, it must be possible for an application 
to request that the resources needed for bearer establishment are 
successfully allocated before the destination user is alerted. Note, 
however, that it must be also possible for an SIP application in a 
terminal to alert the user before the radio resources are established 
(e.g., if the user wants to participate in the media negotiation). 


We believe that this requirement is met by Integration of Resource 
Management and SIP [15]. 


4.5.2.2. Destination User Participates in the Bearer Negotiation 


In establishing a SIP session, it must be possible for a terminating 
application to allow the destination user to participate in 
determining which bearers will be established. However, it must be 
possible to establish the SIP session without user intervention. 


We believe that this requirement is met by the standard SDP 
negotiation described in SIP [2], the SDP offer/answer model [11] and 
the extensions described in Integration of Resource Management and 
SIP 


4.5.2.3. Successful Bearer Establishment 


Successful bearer establishment must include the completion of any 
required end-to-end QoS signaling, negotiation, and resource 
allocation. 


We believe that this requirement is met by the procedures described 
in the Integration of Resource Management and SIP [15]. 
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4.6. Prevention of Theft of Service 


Typically, users are allocated QoS resources. There is an admission 
control mechanism that prevents users exceeding the limits negotiated 
with the network. The network must prevent unauthorized users to 
make use of non-authorized resources. For instance, the network must 
provide a mechanism to prevent a user from using the resources 
allocated to a second user, and for which this second user may be 


paying. 


We believe that this requirement may be met by the procedures 
described in the Private SIP extensions for Media Authorization [16]. 


4.7. Radio Resource Authorization 


As radio resources are very valuable, the network must be able to 
manage them in a controlled manner. The network must be able to 
identify who is using these resources and to authorize their usage. 
For example, a mobile device terminal could execute an unlimited and 
uncontrolled resource reservation procedure if the network does not 
supervise the usage of radio resources. 


We believe that this requirement is met by the procedures described 
in the Private SIP extensions for Media Authorization [16]. 


4.8. Prevention of Malicious Usage 


The 3GPP IMS must prevent mobile devices from making malicious use of 
the network. For instance, a malicious UA could not obey the 
procedures related to the Record-Route header field: when sending 
subsequent requests the UA could bypass proxies which inserted a 
Record-Route header during the initial transaction. 


4.9. Prevention of Denial of Service 
The risk that a proxy will receive a denial of service attack should 
be minimized. For instance, a malicious mobile device could learn a 


SIP proxy IP address and port number (e.g., in a Record-Route header 
value) and establish an attack upon that proxy. 
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4.10. Identification of Users 
4.10.1. Private User Identity 


In order to use the 3GPP IMS, a user is assigned a private user 
identity. The home network operator assigns the private user 
identity, which is used to identify the user uniquely from a network 
perspective. The private user identity is used, for example, for 
authentication, authorization, administration, and, possibly, 
accounting purposes. Note that the private user identity is not used 
for routing of SIP messages. 


The private user identity is a unique global identity defined by the 
Home Network Operator. The identity takes the form of a Network 
Access Identifier (NAI) as defined in RFC 2486 [6]. 


The end user does not have access to the private user identity. 
Typically the identity is stored in a Subscriber Identity Module 
card. 


The private user identity is permanently allocated to a user (it is 
not a dynamic identity), and is valid for the duration of the user's 
business subscription with the home network. 


4.10.1.1. Private User ID in Registrations 


The mobile UA must deliver the private user identity to the SIP 
outbound proxy and the registrar at registration time. 


The private user identity is used as the basis for authentication 
during registration of the mobile user. The term authentication is 
used in this document with the same meaning as it is defined in RFC 
2828 [7]. 


We believe that this requirement is met by populating the username 
field of the Authorization: header value of the REGISTER request with 
the private user identity. 


4.10.2. Public User Identities 


In order to use the 3GPP IMS, a user is assigned one or more public 
user identities. The user will make use of the public user identity/ 
identities when requesting communication to other users. For 
example, the public user identity might be included on a business 
card. 
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Different public user identities may be grouped into a user profile. 
A user may have different profiles, each one containing different 
public user identities. A public user identity can be part of a 
single user profile. 


The user may need to register one or more public user identities 
prior to receiving communications addressed to that public user 
identity. 


We believe that this requirement is met by populating the From: and 
To: header values of a REGISTER message with the public user 
identity. 


4.10.2.1. Format of the Public User Identities 


The public user identity must take the form of a SIP URI (as defined 
in RFC 3261 [2] and RFC 2396 [4]) or of a E.164 [34] number. 


We believe that this requirement is met by using SIP URLs and 
telephone numbers represented in SIP URLs as described in SIP [3]. 
In addition, tel: URLs as specified in RFC 3966 [35] can be used to 
fulfill the requirement. 


4.10.2.2. Registration of Public User IDs 


It must be possible to register globally (i.e., through one single UA 
request) a user that has more than one public identity that belongs 
to the same user profile, via a mechanism within the IMS. In this 
case, the user will be registered with all the public identities 
associated to a user profile. 


We believe this requirement may be accomplished by external 
procedures. For example, the user's profile may contain a list of 
alias identities that the registrar considers active if the primary 
identity is registered. The user may get informed of the 
automatically registered public user IDs by subscribing to its own 
registration state. 


4.10.2.3. Authentication of the public user ID 
Public user identities are not authenticated by the 3GPP IMS. 
However, the network authorizes that the public user identity is 
associated with the registered private user identity. 
There is a list of public user identities associated with each 


private user ID within the IMS. IMS will reject attempts to use 
other public identities with this private user ID. 
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4.10.3. Delivery of the Dialed Public User ID 


Typically a UA will be registered under a set of different public 
user IDs. As such, sessions destined to the user can be placed with 
any of the registered public user IDs. The serving proxy and 
application server(s) in the termination network may apply certain 
filtering rules or services based on the public user ID contained in 
the Request-URI. The UA may also apply certain filtering rules or 
services based on the called public user ID. 


Therefore, it must be possible for all sessions to deliver the dialed 
public user ID to the terminating entities, such as the serving 
proxy, application servers, and terminating UA. 


4.11. Identifiers Used for Routing 


Routing of SIP signaling within IMS must use SIP URLs as defined in 
SIP [2]. E.164 [34] format public user identities must not be used 
for routing within IMS, and session requests based on E.164 format 
public user identities will require conversion into SIP URI format 
for internal IMS usage. 


We believe that this requirement is achieved by translating E.164 
numbers into SIP URIs. A database, such as ENUM [9], might do the 
job. 


4.12. Hiding Requirements 
Although the requirements included in this section are not optional, 
the hiding feature is optional to use through configuration. This 
means that a network operator can, at his desire, switch the hiding 


functionality on or off. 


4.12.1. Hiding of the Network Structure 


A network operator need not be required to reveal the internal 
network structure to another network (in Via, Route, or other 
headers) that may contain indication of the number of SIP proxies, 
domain name of the SIP proxies, capabilities of the SIP proxies, or 
capacity of the network. 


4.12.2. Hiding of IP Addresses 


A network need not be required to expose the explicit IP addresses of 
the nodes within the network (excluding firewalls and border 
gateways). 
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4.12.3. SIP Hiding Proxy 


In order to support the hiding requirements, a SIP hiding proxy may 
be included in the SIP signaling path. This additional proxy may be 
used to shield the internal structure of a network from other 
networks. 


4.13.  Cell-ID 


The identity of the cell through which the 3GPP UA is accessing the 
IMS (Cell-ID) may be used by the home network to provide localized 
services or information on the location of the terminal during an 
emergency call (when emergency calls are handled in IMS; see also the 
requirement stated in Section 4.16). 


4.13.1.  Cell-ID in Signaling from the UA to the Visited and Home 
Networks 


Assuming that the Cell-ID is obtained by the UA by other mechanisms 
outside the scope of SIP, the Cell-ID must be transported at least in 
the following procedures: 


Registration 

Session Establishment (Mobile Originated) 
Session Establishment (Mobile Terminated) 
Session Release 


0000 


The Cell-ID is private information and only of interest in the UA 
home network. Therefore, the Cell-ID should be removed prior to 
sending the SIP signaling beyond the originating home network. 


4.13.2. Format of the Cell-ID 


The cell-ID must be sent in any of the formats described in the 3GPP 
Technical Specification 23.003 [260]. 


4.14. Release of Sessions 


In addition to the normal mechanisms for releasing a SIP session 
(e.g., BYE), two cases are considered in this section: the ungraceful 
session release (e.g., the terminal moves to an out-of-coverage zone) 
and the graceful session release ordered by the network (e.g., 
prepaid caller runs out of credit). 


We believe that this requirement is met by a SIP entity acting as a 
So-called transparent back-to-back UA. 
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4.14.1. Ungraceful Session Release 


If an ungraceful session termination occurs (e.g., a flat battery or 
a mobile leaves coverage), when a call stateful SIP proxy server 
(such as the SIP serving proxy at home) is involved in a session, 
memory leaks and, eventually, server failure can occur due to hanging 
state machines. To ensure stable server operation and carrier grade 
service, a mechanism to handle the ungraceful session termination 
issue must be provided. We assume that there is a mechanism by which 
the SIP outbound proxy is notified, by a mechanism external to SIP, 
of the ungraceful session termination. This allows transforming the 
ungraceful session release into a graceful session release ordered by 
the network (see the next section). For example, upon reception of 
the notification of loss of mobile radio coverage, the SIP outbound 
proxy could send a BYE request on behalf of the terminal, although 
this BYE cannot be authenticated. 


4.14.2. Graceful Session Release 
There must be a mechanism whereby an entity in the network may order 
the release of resources to other entities. This may be used, for 
example, in prepaid calls when the user runs out of credit. 
This release must not involve any request to the UA to send out a 
release request (BYE), as the UA might not follow this request. The 
receiving entity needs the guarantee that resources are released when 
requested by the ordering entity. 
The following objectives must be met: 


o Accurately report the termination to the charging subsystem. 


o Release the associated network resources: bearer resources and 
signaling resources. 


o Notify other parties to the session, if any, of the session 
termination. 


When feasible, this mechanism should be at the SIP protocol level in 
order to guarantee access independence for the system. 
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4.15. Routing of SIP Messages 
4.15.1. SIP Outbound Proxy 


The 3GPP architecture includes a SIP outbound proxy that is typically 
located in the visited network (although it may be located in the 
home network). This outbound proxy provides local services such as 
compression of SIP messages or security functions. In addition, the 
outbound proxy may interact with the media reservation mechanism to 
provide authentication and authorization support for media 
reservation. 


All mobile terminal originated session setup attempts must transit 
the outbound proxy so that the services provided by the outbound 
proxy can be delivered to the mobile terminal. 


4.15.2. SIP Serving Proxy in the Home Network 


The serving proxy in the home network allows triggering of user- 
customized services that are typically executed in an application 
server. 


All mobile terminal originated session setup attempts must transit 
the serving proxy in the home network so that the proxy can properly 
trigger the SIP services allocated to the user (e.g., speed dial 
substitution). This implies a requirement for some sort of source- 
routing mechanism to ensure these proxies are transited correctly. 


4.15.3. INVITE Might Follow a Different Path than REGISTER 
The path taken by an INVITE request need not be restricted to the 


specific path taken by a mobile terminal originated REGISTER request; 
e.g., the INVITE may traverse just the SIP outbound proxy and the SIP 


serving proxy, without passing through any other proxies. However, 
the path taken by the INVITE may follow the same path taken by the 
REGISTER. 


4.15.4. SIP Inbound Proxy 


The visited network may apply certain services and policies to 
incoming sessions (such as establishment of security services or 
interaction with the media reservation mechanism). Therefore, the 
visited network may contain a SIP inbound proxy for terminating 
sessions. In general, the SIP inbound proxy and the SIP outbound 
proxy are the same SIP proxy. 
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4.15.5. Distribution of the Source Routing Set of Proxies 


Sections 4.15.2 and 4.15.4 assume that a source-routing mechanism is 
used to effect traversal of the required SIP proxies during session 
setup. 


There must be some means of dynamically informing the node that adds 
the source-routing set of proxies that the INVITE has to traverse 
(e.g., the outbound proxy or serving proxy) of what that set of 
proxies should be. 


The hiding requirements expressed in Section 4.12 also apply to the 
said set of proxies. 


4.16. Emergency Sessions 
3GPP networks already contain alternative procedures for delivering 
emergency sessions. Release 5 of the 3GPP specifications does not 
add any requirement for SIP emergency sessions. 

4.17. Identities Used for Session Establishment 


4.17.1. Remote Party Identification Presentation 


It must be possible to present to the caller the identity of the 
party to which he/she may dial back to return a call. 


We believe that this requirement is met by the procedures described 
in RFC 3325 [17]. 


4.17.2. Remote Party Identification Privacy 


In addition to the previous requirement, the called party must be 
able to request that his/her identity not be revealed to the caller. 


We believe that this requirement is met by the procedures described 
in RFC 3323 [18]. 


4.17.3. Remote Party Identification Blocking 


Regulatory agencies, as well as subscribers, may require the ability 
of callers to block the display of their caller identification. The 
destination subscriber's SIP serving proxy may be perform this 
function. In this way, the destination subscriber is still able to 
do a session-return, session-trace, transfer, or any other 
supplementary service. 
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Therefore, it must be possible that the caller request to block the 
display of his/her identity on the callee's display. 


We believe that this requirement is met by the procedures described 
in RFC 3323 [18]. 


4.17.4. Anonymity 
Procedures are required for anonymous session establishment. 


However, sessions are not intended to be anonymous to the originating 
or terminating network operators. 


We believe that this requirement is met by the procedures described 
in RFC 3323 [18] and RFC 3325 [17]. 


4.17.5. Anonymous Session Establishment 


If the caller requests that the session be anonymous, the User Agent 
Client (UAC) must not reveal any identity information to the User 
Agent Server (UAS). 


If the caller requests that the session be anonymous, the terminating 
network must not reveal any identity or signaling routing information 
to the destination endpoint. The terminating network should 
distinguish at least two cases: first, whether the caller intended 
the session to be anonymous, and second, whether the caller's 
identity was deleted by a transit network. 


We believe that this requirement is met by the procedures described 
in RFC 3323 [18] and RFC 3325 [17]. 


4.18. Charging 


The 3GPP charging implications are described in the 3GPP Technical 
Specification 32.225 [31]. 


4.18.1. Support of Both Prepaid and Postpaid Models 


Operators may choose to offer prepaid and/or postpaid services. The 
prepaid model is accomplished with the support of the online charging 
model. The postpaid model is accomplished with the support of the 
offline charging model. 


Online charging is the process whereby charging information can 
affect, in real-time, the service rendered to the user, such as a 
request for a graceful release of an existing session. Online 
charging interacts with the SIP signaling. 
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Offline charging is the process whereby charging information does not 
affect, in real-time, the service rendered to the user. 


4.18.2. Charging Correlation Levels 


The following levels of correlation for IMS charging are considered: 


o 


Correlation within a session. A session may comprise a number of 
media components. It must be possible to correlate the charging 
data of the different media components belonging to a session. 


Correlation at media-component level. For a session comprising 
several media types (such as audio and video), charging data is 
generated for each media type and needs to be correlated between 
network elements. For this, a media identifier will be unique and 
will clearly identify which media type of a session this charging 
information belongs to. This component identifier is not 
exchanged between network elements and is based on the ordering of 
media flows in the SDP. This ordering is the same as that used in 
the binding information passed to the GPRS network. 


4.18.3. Charging Correlation Principles 


To support the correlation of charging information, the following 
principles apply to both offline and online charging: 


o 


The correlation of charging information for an IMS session is 
based on the use of IMS Charging Identifiers (ICID). 


The first IMS network entity within the SIP signaling path is 
responsible for assigning an ICID. This ICID will then be passed 
along the whole session path in an end-to-end manner. However, 
this will not preclude further elements (other SIP proxies) along 
the session path from generating additional identifiers to be 
passed along. 


The ICID is passed to all IMS network entities in the session 
signaling path. This is performed using SIP signaling. 


The addresses of the charging functions are passed by the serving 
SIP proxy to all IMS network entities in the session signaling 
path. This is to provide a common destination for all the 
charging records generated by each IMS network entity with the 
same ICID. 


For the charging correlation between the GPRS network and the IMS, 
one or more GPRS Charging IDs, which identify the PDP contexts of 
the session, are passed from the GPRS network to the IMS. 
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o The GPRS Charging IDs are passed by the outbound SIP proxy to the 
serving SIP proxy and the Application Servers using SIP signaling. 
They are not transferred from one home IMS (e.g., Caller's home) 
to another (e.g., callee's home). 


o Inter Operator Identifiers (IOI) are shared between the caller's 
home IMS and the callee's home IMS to provide identifiers of the 
home originating and home terminating networks. 


4.18.4. Collection of Session Detailed Information 


The SIP serving proxy or another SIP server in the home network must 
be able to log details of all sessions, such as the duration, source, 
and destination of a session, to provide to the charging subsystem. 


4.19. General Support of Additional Capabilities 
4.19.1. Additional Capabilities 


3GPP is interested in applying and using additional services, such as 
those described in SIP Call Control - Transfer [20], SIP Basic Call 
Flow Examples [21], SIP Public Switched Telephone Network (PSTN) Call 
Flows [22], and SIP service examples [23]. Although 3GPP is not 
going to standardize additional services, 3GPP may make sure that the 
capabilities that enable those services are granted in the network. 


Therefore, we believe that the SIP REFER method [24] and the Replaces 
header [25] constitute a complement to be used as an enabler in order 
to meet the above requirement. 


4.19.2. DTMF Signaling 


Support for voice calls must provide a level of service similar to 
that of the existing circuit-based voice service. This includes the 
ability to use DTMF signaling, for example, for control of 
interactive voice response systems such as ticket sales lines and 
timetable information. 


The transport of DTMF tones from the mobile terminal to target 
systems that may be in the PSTN, or to SIP-based solutions (i.e., no 
PSTN connection), must be supported. 


The transport of DTMF signals may be required for the whole call, 
just for the first part, or from some later point in the call. The 


Start time and duration of such signaling is therefore unpredictable. 


We believe that the mechanisms specified in RFC 2833 [8] meet the 
requirement without impacting SIP. 
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4.19.3. Early Media 


As mobile terminals will frequently interoperate with the PSTN, 
support for early media is required. 


4.20. Exchange of Session Description 


Typically a session description protocol such as SDP is used in SIP 
to describe the media streams and codecs needed to establish the 
session. SIP uses an offer/answer model of the session description, 
as described in RFC 3264 [11], in which one of the parties offers his 
session description and the other answers that offer. 


In the 3GPP IMS, the mobile terminals might have restrictions with 
the memory, DSP capacity, etc. As such, a mechanism is required by 
which the Session Description negotiation may conclude with one out 
of many codecs per media stream. Both UAC and UAS must know, prior 
to any media being sent or received, which codec is used for each 
media stream. 


In the 3GPP IMS, efficient use of the network and radio resources is 
an important requirement. As such, the network should know in 
advance which codec is used for a particular media stream. The 
network access control may use this information to grant access to 
the network and to control the resource utilization. 


Additionally, it is required that the party who pays for the resource 
utilization have the opportunity to decide which codecs to use, once 
both end parties are aware of the capabilities supported at the 
remote UA. 


Therefore, a mechanism is required by which both UAC and UAS have the 
ability to negotiate and trim down the number of codecs used per 
media stream, so that at the end of the negotiation there can be a 
reduced set of agreed codecs per media stream. 


We believe that the mechanism specified in RFC 3264 [11] meets the 
requirement. 
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4.21. Prohibition of Certain SDP Parameters 
4.21.1. Prohibition of Codecs 


The SIP outbound proxy may contain local policy rules with respect 
the codecs allowed in the network. For instance, certain networks 
may disallow high-bandwidth-consuming audio codecs. There has to be 
a mechanism whereby the SIP outbound proxy can reject a session 
establishment attempt when a codec is prohibited in the network due 
to local policy. 


4.21.2. Prohibition of Media Types 


Certain users” subscriptions may include restrictions on certain 
media types. For instance, a user may not be allowed to establish a 
video session. The SIP serving proxy in the home network downloads 
the user profile, which contains the rules for these kinds of 
restrictions. 


As the establishment of sessions traverse the SIP serving proxy in 
the home network, the proxy can prohibit an attempt to establish a 
session that includes a non-allowed media type for the user. 
Therefore, there has to be a mechanism whereby the SIP serving proxy 
Can reject a session establishment attempt when the session includes 
a forbidden media type. 


4.22.  Network-initiated Re-authentication 


Network operators need to authenticate users to ensure that they are 
charged appropriately for the services they use. The 
re-authentication done when the user initiates a message will not 
suffice for this purpose, as described below. 


If the duration of the authentication period is set to a relatively 
low value to ensure that the user cannot incur a high amount of 
charges between two authentications, it may create a lot of 
unnecessary authentications of users that have remained largely 
inactive, and therefore it may use unnecessary air interface 
resources. 


If the duration of the authentication period is set to a relatively 


high value to avoid these unnecessary authentications, the risk is 
then that some users may incur high charges between authentications. 
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A user's authentication is automatically invalidated when a certain 
threshold for charges (or number, or duration of sessions) is reached 
without giving the user a chance to re-authenticate, even if a valid 
registration exists. This would not provide an adequate level of 
service. 


Consequently, it must be possible for the network to initiate a 
re-authentication process at any time. The triggers must be set 
within the network and may include charging thresholds, number of 
events, session duration, etc. 


4.23. Security Model 


Sections 4.23, 4.24, and 4.25 have been based on the 3GPP Technical 
Specifications 33.203 [32], 23.228 [28], and 33.210 [33]. 


The scope for security of the 3GPP IMS is the SIP signaling between 
the various SIP entities. Protecting the end-to-end media streams 
may be a future extension, but it is not considered in the Release 5 
version of the IMS specifications. 


Each operator providing IMS services acts as its own domain of trust 
and shares a long-term security association with its subscribers 
(e.g., pre-shared keys). Operators may enter into roaming agreements 
with other operators, in which case a certain level of trust exists 
between their respective domains. 


SIP UAs must authenticate to their home network before the use of IMS 
resources is authorized. In Release 5 of the 3GPP IMS 
specifications, authentication is performed during registration and 
re-registrations. 


Portions of the SIP signaling must be protected hop by hop. Looking 
at Figure 1 in Section 3, we can distinguish two distinct zones where 
the required security is unique: 


o Access Domain: Between the SIP user device and the visited 
network. 


o Network Domain: Between the visited and home networks, or inside 
the home network. 


Characteristics needed in the Access Domain are quite different from 
those of the Network Domain because of the terminal's requirements 
for mobility, computation restriction, battery limit, bandwidth 
conservation, and radio interface. SIP entities in the access domain 
should be able to maintain security contexts with a large group of 
users in parallel. Furthermore, Access Domain provides user-specific 


Garcia-Martin Informational [Page 27] 


RFC 4083 3GPP R5 Requirements on SIP May 2005 


security associations, whereas Network Domain provides security 
associations between network nodes. Therefore, the weight of 
protocols and algorithms and their compliance with compression 
mechanisms are very important to Access Domain Security. It is 
therefore required that the security solutions allow different 
mechanisms in these two domains. 


4.24. Access Domain Security 
4.24.1. General Requirements 
4.24.1.1. Scalability and Efficiency 


3GPP IMS is characterized by a large subscriber base of up to a 
billion users, all of which must be treated in a secure manner. 


The security solutions must allow global roaming among a large number 
of administrative domains. 


4.24.1.2. Bandwidth and Round-trips 


The wireless interface in 3GPP terminals is an expensive resource 
both in terms of power consumption and maximum use of scarce 
spectrum. Furthermore, cellular networks typically have long 
round-trip time delays, which must be taken in account in the design 
of the security solutions. 


Any security mechanism that involves 3GPP terminals should not 
unnecessarily increase the bandwidth needs. 


All security mechanisms that involve 3GPP terminals should minimize 
the number of necessary extra round-trips. In particular, during 
normal call signaling there should not be any additional security- 
related messages. 


4.24.1.3. Computation 


It must be possible for mobile device terminals to provide security 
without requiring public key cryptography and/or certificates. 3GPP 
IMS may, however, include optional security schemes that employ these 
techniques. 


Current HTTP authentication methods use only symmetric cryptography, 
as required here.  Lower-layer mechanisms (IKE, TLS) require 
implementation of public-key cryptography e.g., Diffie-Hellman. If 
these lower-layer mechanisms were used, the mobile terminal would 
authenticate and negotiate session keys with the visited network 
using only symmetric methods. 
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4.24.1.4. Independence of the Transport Protocol 


The selected security mechanism should work with any transport 
protocol allowed by SIP (e.g., TCP, UDP). 


4.24.2. Authentication 
Authentication, as used in this context, means entity authentication 
that enables two entities to verify the identity of the respective 
peer. 


4.24.2.1. Authentication Method 


A strong, mutual authentication must be provided. 


The authentication method must be able to work when there are zero or 
more SIP proxies in the SIP path between the authenticator and the 
authenticated user. 


It must be possible to support extensible authentication methods. 
Therefore, authentication using an extensible authentication 
framework is strongly recommended. 


Authentication methods based on the secure storage of long-term keys 
used for authentication and the secure execution of authentication 
algorithms must be supported. 


The SIP client's credentials must not be transferred as plain text. 


3GPP intends to reuse UMTS AKA [13]. UMTS AKA applies a symmetric 
cryptographic scheme, provides mutual authentication, and is 
typically implemented on a so-called SIM card that provides secure 
storage on the user's side. 


Additional requirements related to message protection that apply to 
the authentication method are stated in Section 4.24.3. 


4.24.3. Message Protection 
4.24.3.1. Message Protection Mechanisms 


SIP entities (typically a SIP client and a SIP proxy) must be able to 
communicate using integrity. By integrity, we mean the ability for 
the receiver of a message to verify that the message has not been 
modified in transit.  SIP entities should be able to communicate 
confidentially. In 3GPP IMS, these protection modes must be based on 
initial authentication. Integrity protection and confidentiality 
must be possible using symmetric cryptographic keys. 
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It must also be possible to handle error conditions in a satisfactory 
manner as to allow recovery (see also sections 4.3.6.3 and 4.14). 


It must be possible to provide this protection between two adjacent 
SIP entities. In future network scenarios, it may also be necessary 
to provide this protection through proxies, though the 3GPP Release 5 
IMS does not require this. 


The security mechanism must be able to protect a complete SIP 
message. 


If header compression/removal or SIP compression is applied to SIP 
messages, it must be compatible with message protection. 


4.24.3.2. Delegation 


3GPP IMS implements distributed security functions responsible for 
authentication and message protection. 


It must be possible to perform an initial authentication based on 
long-term authentication credentials, followed by subsequent 
protected signaling that uses short-term authentication credentials, 
such as session keys created during initial authentication. The 
authentication mechanism used is able to provide such session keys. 
It must be possible to apply subsequent message protection as soon as 
possible, even during the initial authentication period. 


Initial authentication is performed between the SIP UA and the 
authenticating SIP serving proxy in the home network. However, the 
authentication mechanism must not require access to the long-term 
authentication credentials in these nodes. In the home network, the 
authenticating SIP serving proxy must support interaction with a 
dedicated authentication server in order to accomplish the 
authentication task. At the client side, a secured 
(tamper-resistant) device storing the long-term credentials of the 
user must perform the authentication. 


Additionally, the SIP serving proxy that performed the initial 
authentication must be able to delegate subsequent SIP signaling 
protection (e.g., session keys for integrity or encryption) securely 
to an authorized SIP proxy further downstream. The tamper-resistant 
device at the client side must be able to delegate the session keys 
securely to the SIP UA. 
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4.24.4. Negotiation of Mechanisms 


A method must be provided to negotiate the security mechanisms to be 
used in the access domain securely. 


This method must at least support the negotiation of different 
security mechanisms providing integrity protection and encryption, 
algorithms used within these mechanisms, and additional parameters 
that they require in order to be exchanged. 


The negotiation mechanism must protect against attackers who do not 
have access to authentication credentials. In particular, the 
negotiation mechanism must be able to detect a possible 
man-in-the-middle attacker who could influence the negotiation result 
so that services with weaker security or with none are negotiated. 


A negotiation mechanism is generally required in all secure protocols 
to decide which security services to use and when they should be 
started. This security mechanism serves algorithm and protocol 
development as well as interoperability. Often, the negotiation is 
handled within a security service. For example, the HTTP 
authentication scheme includes a selection mechanism for choosing 
among appropriate algorithms. Note that when referring to 
negotiation we mean just the negotiation, not all functions in 
protocols such as IKE. For instance, we expect that the session key 
generation is to be a part of the initial authentication. 


SIP entities must be able to use the same security mode parameters to 
protect several SIP sessions without re-negotiation. For example, 
Security mode parameters may be assumed to be valid within the 
lifetime of a registration. Note that it is necessary to amortize 
the cost of security association setup and parameter negotiation over 
several INVITEs. 


4.24.5. Verification of Messages 


4.24.5.1. Verification at the SIP Outbound Proxy 


The SIP outbound proxy must be able to guarantee the message origin 
and to verify that the message has not been changed (e.g., it is 
integrity protected). 


4.24.5.2. Verification at the SIP Serving Proxy 
The serving SIP proxy needs to receive an indication if the outbound 


proxy was able to verify the message origin and, in the case of a 
REGISTER request, whether or not it was integrity protected. 
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4.25. Network Domain Security 


Message authentication, key agreement, integrity and replay 
protection, and confidentiality must be provided for communications 
between SIP network entities such as proxy servers. 


Network domain security mechanisms must be scalable up to a large 
number of network elements. 


3GPP intends to make having the protection discussed above mandatory 
at least between two operators, and optional within an operator's own 
network. Security gateways exist between operator's networks. 


We believe that the above requirements are fulfilled by applying 
security mechanisms as specified in the current IP Security standards 
in RFC 2401 [5]. 


5. Security Considerations 


This document does not define a protocol, but still presents some 
security requirements to protocols. The main security requirements 
are stated in sections 4.23, 4.24, and 4.25. Additional 
security-related issues are discussed under sections 4.6, 4.7, 4.8, 
4.9,- 4. LOr and 4.12. 
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